For the purposes of this application the terminology Voice over Internet Protocol (VoIP) or telephony are not limited to voice but could be any media, including for example voice, video, instant messaging, combinations of voice and video etc.
For the purposes of this application, the terminology of Public and Private Network are intended to encompass not only truly public or private networks, but may also include enterprise or any network where the IP address space are either private or not. However, the distinction between Public and Private is obviously relative and Private networks are generally more private than Public networks.
Various forms of communications can be performed in packet based networks, such as electronic mail, web browsing, file transfer and so forth. With the increased capacity and reliability of packet based networks, voice communications (along with other forms of real time, interactive communications) have also become feasible. In such communications, voice and other real time data are carried in packets that are sent across the networks.
Various standards have been proposed for voice and multimedia communications over packet based networks. One such standard is the H.323 Recommendation from the International Telecommunications Union (ITU). Another standard for voice and multimedia communications is the Session Initiation Protocol (SIP), as developed by the Internet Engineering Task Force (IETF). Generally, H.323, SIP, and other control protocols are used for negotiating session information to coordinate the establishment of a communications session. Once negotiation setup has been completed, packetised media (including voice or other forms of real time data) can flow between end points. A media transport protocol, such as the real time protocol (RTP), can be used for conveying packetised media between the end points.
Various issues are associated with communications over packet based networks. One is the dwindling supply of globally unique public addresses, such as IP addresses. To address this problem, network address translation (NAT) is provided to enable address translations between public and private networks. By reusing pools of public IP addresses as private addresses in different private networks, the virtual supply of network addresses is extended.
NAT effectively allows an enterprise to use whatever addresses it chooses for end points in the network of the enterprise provided that packets destined for a public network are mapped to globally unique public addresses and vice versa at the received end. However, enterprises typically follow the IP addressing recommendations provided in the IETF Request for Comments (RFC) 1918.
FIG. 1 is a block diagram depicting logically an exemplary, known arrangement of first and second enterprise IP networks 10 and 12. The two enterprise IP networks 10, 12 are connected by a SP public IP network 16. In this context, “public IP network” encompasses IP networks such as the internet which are freely accessible by users, subject to users having appropriate hardware and/or service ware (e.g. an internet service provider (ISP) service), and private IP networks owned by SPs, such networks usually being accessible on a subscription or other financial basis by clients of the SPs. The term “SP” can be considered to include the public carrier network operators and ISPs, or consortiums thereof, who offer shared IP network infrastructures.
First enterprise IP network 10 comprises a network of media endpoints (MEs) 18a, b . . . n, served by a NAT router 20. Similarly, second enterprise IP network 12 comprises a network of MEs 22a, b . . . m served by a NAT router 24. Each of the NAT routers 20, 24 interface with a call agent (CA) 26 of the SP network 16 through appropriate SP network edge devices (not shown). Such edge devices will be familiar to a skilled artisan and so need not be described here.
The CA 26 is a centralised call agent server of the SP network 16 responsible for processing communication session setup requests initiated by the MEs (18, 22) of the first and second enterprise IP networks 10,12 for establishing paths between the MEs (18, 22) and for other MEs external to the enterprise IP networks 10,12. The MEs (18, 22) could comprise user terminals such as personal computer (PC) work stations, network telephones (i.e. telephones having a network interface to enable communication with a packet based network) or other terminals capable of participating in real time interactive communications sessions.
The enterprise IP network 10 may comprise an IP VPN hosted by the SP network 16. This is represented logically by the dashed line 28A in FIG. 1. Whilst the first enterprise IP network 10 is represented by a single cloud 10 in FIG. 1, it will be understood that such a network might comprise a number of geographically separate enterprise locations (sites) served by a single IP VPN hosted by the SP network 16. In such a case, NAT routers serving said geographically separate enterprise locations would logically comprise a single NAT function for the enterprise IP VPN. In the context of this invention, the term “enterprise” can also be construed as encompassing private networks such as a small office home offices (soHos), for example. An IP VPN provides the appearance of a single IP data network over a shared medium which in the arrangement depicted by FIG. 1 is the SP network 16. The IP VPN may have a common, private IP address space across the sites of the enterprise.
In the case where the MEs (18) of the first enterprise IP network 10 have telephony capabilities (represented logically by numeral 21 in FIG. 1) then such MEs would, in respect of their telephony applications, comprise a telephony VPN (represented logically by dashed line 30A in FIG. 1) which would be served by the IP VPN 28A. Together, the telephony VPN 30A and the IP VPN 28A comprise a VoIP VPN for the first enterprise IP network 10.
Similarly to the first enterprise IP network 10, the second enterprise IP network 12 comprises an IP VPN hosted by the SP network 12. This IP VPN is represented logically by the dashed line 28B in FIG. 1. Telephony enabled MEs (represented by numeral 23 in FIG. 1) of the second enterprise IP network 12 comprises a telephony VPN (denoted by dotted line 30B in FIG. 1) and, together with the IP VPN 28B, comprises a VoIP VPN for the second enterprise IP network 12.
Consider the case where a media end point ME1 in the first enterprise IP network 10 initiates a communications session setup request for a communications session with an external media end point eME 32, where eME 32 is connected to the SP network 16 by an appropriate, known edge device (not shown). At a first enterprise IP network 10 private address side of NAT router 20, identified by arrow A in FIG. 1, the source/destination IP address/port pairs associated with the communications session setup request between ME1 and eME 32 will be as shown in the following table:—
TABLE 1Source IP address10.1.1.1 (private)Source Port1000Destination IP address201.3.3.3 (public)Destination Port2020
In Table 1, the source IP address is the private IP address allocated to ME1 within the first enterprise IP network 10, i.e. this is the address of ME, as it appears behind the NAT router 20. The source port is the port allocated to the communications session setup request from ME1. Allocation of this port may be static in that it is always allocated to communications session setup requests from ME1, but more usually it will be media flow specific. In other words, the port allocated as a result of a communications session setup request from ME1 will normally depend on the media application which forms the basis for the request such that a predetermined NAT private address side port will be allocated to ME1 for say a voice over IP (VoIP) media flow and a different predetermined port allocated to ME1 for, say, a web browser media flow.
The destination IP address and destination port are the public address/port pair for eME 32.
Once a communications session setup request from ME1 has passed through NAT router 20 to a point identified by arrow B in FIG. 1, the source IP address/port pair for ME1 has been translated. This is illustrated in Table 2:—
TABLE 2Source IP address201.3.3.20 (public)Source Port2000 (assigned by NAT 20)Destination IP address201.3.3.3 (public)Destination Port2020
The source IP address for ME1 is now a public, globally unique IP address for the NAT router 20. The NAT router 20 may have a pool of public, globally unique IP addresses from which the source IP address for ME can be selected. The source port is a port on the public IP address side of NAT router 20 associated with ME1. This port may be allocated from a pool of not presently in use ports of the NAT router 20. As such, it is dynamically allocated for the communications session between ME1 and eME 32.
It can therefore be seen that CA 26 cannot associate a specific NAT router private source IP address/port pair to a public source IP address/port pair for a communications session setup request originating from ME1 since there is no fixed relationship created by the network address translation process between said IP address public and private pairs.
The private address side source port may be allocated on a media flow specific basis in addition to a per session basis and thus there could be multiple different ports respectively available for multiple different media flow types. The public address side source port may be dynamically allocated from a pool of not presently in use ports leading to perhaps an even larger pool of ports from which the public address side source port can be selected compared to that for the private address side source port selection. Even if the CA 26 had knowledge of the possible permutations of pairs of private IP source address/port pairs and public IP source address/port pairs, it cannot know which permutation will be utilised in advance of receipt of a communications session setup request.
Where a communications session setup request relates to the establishment of a communications session between a first enterprise ME behind a first NAT having a private IP address with a second enterprise ME behind a second NAT also having a private IP address, that the communications session setup will involve at least two NAT processes such that the first ME will effectively see as its destination the public IP address of the NAT router associated with the second ME and vice versa.
Referring again to FIG. 1, when, say, ME, of first enterprise IP network 10 makes a communications session setup request to establish a communications session with, say, ME2 of the same network 10, the CA 26 has no means of recognising that ME1 and ME2 reside behind the same NAT router 20. Consequently, the communications session setup request is treated in a similar manner to the foregoing example where ME1 sought a communications session with eME 32. Consequently, the media path for IP packet transmission between ME1 and ME2 of network 10 would follow the media path (represented logically by arrowed line 36 in FIG. 1) from ME1, through network 10 local router (shown as dashed outline) 34, through NAT router 20 to SP network 16 returning along generally the same route to reach ME2. It will be understood that packet flow between ME1 and ME2 will be bidirectional along media path 36.
The media path 36 established between ME1 and ME2 illuminates a number of problems with the network address translation media path provisioning process associated with the known network arrangement of FIG. 1. The bandwidth within the SP network 16 allocated to network 10 will be finite and most likely subject to a service level agreement (SLA) where the SLA will specify financial penalties for the enterprise should it exceed agreed bandwidth levels in the SP network 10. It is therefore in the interest of the enterprise to efficiently use the bandwidth resources of the SP network 16. The media path 36 between ME1 and ME2 is not bandwidth efficient since it utilises bandwidth resources on the SP network 16 when logically it is not necessary to do so. For example, ME1 and ME2 may be physically located close to each other in the same location (site) of network 10 and yet the media path 36 between them passes out of the network 10 into the SP network 16. This also wastes the limited bandwidth available on the physical links connecting the network 10 site to the SP network 16. In this latter example, it would be logically more efficient with respect to usage of SP network 16 bandwidth resources if the media path between ME1 and ME2 did not reach the NAT router 20 but which instead physically remained within the network location (site) extending only as far as the local router 34.
A further problem illuminated by the media path 36 between ME1 and ME2 is the introduction of processing delays that might adversely impact real time, interactive media communications between MEs (18). For real time, interactive media communications such as VoIP, it is important to minimise processing delays encountered by the real time media packets in their media paths. In the case of media path 36, logically unnecessary delays incur in that part of the media path 36 extending between the local router 34 and the SP network 16.
A further problem illuminated by the media path 36 is that the present process of network address translation media path establishment is wasteful of the NAT resources which represent a disproportionally expensive part of the network infrastructure, relatively speaking. It follows therefore that this resource should be utilised only when logically necessary.
In the case where an enterprise employs a common, private IP address space across all its sites within an IP VPN, it follows that NAT routers serving the sites logically comprise a single NAT function behind which all the MEs of the enterprise sit. Each site may have a NAT or some sites may share a NAT. In any event, for a communications session between an ME in one site with an ME of another site, it is also the case that no NAT process is logically required for establishing a media path between these two MEs, but as with the foregoing example, the Call Agent has no means of recognising that the most resource efficient path between these two MEs is a path through the enterprise IP VPN facilitated by respective local routers of the enterprise sites using the private IP addresses of said end points for facilitating packet data transmission between them.